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Abstract  -  The  use  of  ontologies  is  on  the  rise,  as  they  facilitate 
interoperability  and  provide  support  for  automation.  Today, 
ontologies  are  popular  in  areas  such  as  the  Semantic  Web, 
knowledge  engineering.  Artificial  Intelligence  and  knowledge 
management.  However,  many  real  world  problems  in  these 
disciplines  are  burdened  by  incomplete  information  and  other 
sources  of  uncertainty  which  traditional  ontologies  cannot 
represent.  Therefore,  a  means  to  incorporate  uncertainty  is  a 
necessity.  Probabilistic  ontologies  extend  current  ontology 
formalisms  to  provide  support  for  representing  and  reasoning  mth 
uncertainty.  Traditional  ontologies  provide  a  hierarchical 
structure  of  entity  classes  and  a  formal  way  of  expressing  their 
relationships  with  first-order  expressivity,  which  supports  logical 
reasoning.  However,  they  lack  built-in,  principled  support  to 
adequately  account  for  uncertainty.  Applying  simple  probability 
annotations  to  ontologies  fails  to  convey  the  structure  of  the 
probabilistic  representation.  Similarly,  other  less  expressi\e 
probability  schemes  do  not  convey  the  ontology  structure,  and  are 
also  inadequate.  Representation  of  uncertainty  in  real-world 
problems  requires  probabilistic  ontologies,  which  integrate  the 
inferential  reasoning  power  of  probabilistic  representations  with 
the  first-order  expressivity  of  ontologies.  Developing  a  probabilistic 
ontology  is  more  complex  than  simply  assigning  probability  to  a 
class  instantiation  or  representing  a  probability  scheme  using 
ontology  constructs.  Standard  ontological  engineering  methods 
provide  insufficient  support  for  the  complexity  of  probabilistic 
ontology  development.  Therefore,  a  specific  methodology  is  needed 
to  develop  probabilistic  ontologies  from  conceptualization  to 
implementation.  We  introduce  a  systematic  approach 
to  probabilisticontology  development  which  focuses  on  evolving  a 
traditional  ontology  from  conceptualization  to  probabilistic 
ontology  implementation  for  real-world  problems.  The 
Probabilistic  Ontology  Development  Methodology  is  an  efficient, 
teachable,  and  repeatable  technique  for  the  development, 
implementation  and  evaluation  of  explicit,  logical  and  defensiUe 
probabilistic  ontologies  developed  for  knowledge -sharing  and 
reuse  in  a  given  domain. 

Keywords —  probabilistic  ontology,  methodology,  inferential 
reasoning 

L  Introduction 

The  use  of  ontologies  is  on  the  rise,  as  they  faeilitate 
interoperability  and  provide  support  for  automation.  Today, 
ontologies  are  popular  in  areas  sueh  as  the  Semantie  Web  [1], 
knowledge  engineering,  Artifieial  Intelligenee  (AI)  and 
knowledge  management  [2].  However,  many  real  world 


Paulo  C.  G.  da  Costa 
Kathryn  B.  Laskey 

Systems  Engineering  and  Operations  Researeh 
George  Mason  University 
Fairfax,  Virginia 
[peosta,  k]askey]@gmu.edu 

problems  in  these  diseip lines  are  burdened  ineonplete 
information  and  other  sourees  of  uneertainty  whieh  traditional 
ontologies  eannot  represent  [3].  Therefore,  a  means  to 
ineorporate  uneertainty  is  aneeessity. 

Ontologies  provide  a  hierarehieal  strueture  of  entity  elasses 
and  a  formal  way  of  expressing  their  relationships  with  first- 
order  expressivity,  whieh  supports  logieal  reasoning.  However, 
they  laek  built-in,  prineipled  support  to  adequately  aeeountfor 
uneertainty.  Applying  sinple  probability  annotations  to 
ontologies  fails  to  eonvey  the  strueture  of  the  probabilistie 
representation.  Similarly,  other  less  expressive  probability 
sehemes  do  not  eonvey  the  ontology  strueture,  and  are  also 
inadequate.  Representation  of  uneertainty  in  real-world 
problems  requires  probabilistie  ontologies,  whieh  integrate  the 
inferential  reasoning  power  of  probabilistie  representations  with 
the  first-order  expressivity  of  ontologies.  Developing  a 
probabilistie  ontology  is  more  eomplex  than  sinply  assigning 
probability  to  a  elass  instantiation  or  representing  a  probability 
seheme  using  ontology  eonstruets.  The  Semantie  Teehnologies 
(ST)  eommunity  needs  a  eonprehensive  methodology  for  the 
development,  inplementation,  and  evaluation  of  probabilistie 
ontologies.  Traditional  ontologieal  engineering  helps  to  ensuie 
that  ontologies  developed  for  knowledge -sharing  and  reuse  aie 
explieit,  logieal,  and  defensible.  However,  these  standaid 
ontologieal  engineering  methods  provide  insuffieient  support 
for  the  eonplexdty  of  probabilistie  ontology  development 
deseribed  above.  Therefore,  a  speeifie  methodology  is  needed  to 
develop  probabilistie  ontologies  from  eoneeptualization  to 
inplementation. 

To  illustrate  the  problem,  suppose  there  exdsts  an  ontology 
of  organisms.  Within  this  ontology  is  a  Mammal  elass  and 
Human  sub -elass.  Entities  of  the  Human  elass  usually  have 
attributes  that  inelude  two  arms,  two  legs,  10  fingers,  10  toes, 
ete.  Yet  humans  have  alternative  numbers  of  digits  for  many 
reasons  (e.g.  injuries,  geneties,  birth  defeets), but  are 
nonetheless  human.  Suppose  Joe  is  bom  with  eight  toes.  The 
diffieulty  in  representation  for  the  Joe  instanee  stems  from  the 
faet  that  the  premise  of  a  valid  argument  (Humans  have  10  toes) 
eanbeuneertain,in  whieh  ease  validity  of  the  argument  inposes 
no  eondition  on  the  eertainty  of  the  eonelusion  (Joe  is  Human). 
Probabilistie  ontologies  address  this  issue  by  expending  eurrent 
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ontology  formalisms  to  provide  support  for  representing  and 
reasoning  with  uneertainty. 

There  is  a  large  body  of  researeh  on  development  of 
traditional  ontologies,  but  these  methodologies  are  not  suitable 
for  produetion  of  probabilistie  ontologies,  as  deseribed  above. 
Development  of  probabilistie  ontologies  without  the  benefit  of  a 
methodology  is  a  risky  venture.  Solutions  tend  to  be  ad -hoe  and 
without  eonsideration  of  interoperability.  The  literature  on 
engineering  probabilistie  ontologies  is  extremely  limited. 
Carvalho  notes, 

“It  would  be  interesting  to  have  a  tool  guiding  the  user  on 
the  steps  neeessary  to  ereate  a  probabilistie  ontology  and  link 
this  doeumentation  to  its  inplementation  . . .  [4].” 

This  paper introduees  a  systematie  approaehto  probabilistie 
ontology  development  whieh  foeuses  on  evolving  a  traditional 
ontology  from  eoneeptualization  to  probabilistie  ontology 
inplementation  for  real-world  problems.  The  Probabilistie 
Ontology  Development  Methodology  is  an  effieient,  teaehable, 
and  repeatable  means  to  develop,  inplement  and  evaluate 
e^lieit,  logieal  and  defensible  probabilistie  ontologies 
developed  for  knowledge-sharing  and  reuse  in  a  given  domain 
[5]. 

A.  Probabilistic  Ontology  Development  Methodology 

We  define  a  Probabilistie  Ontology  Development 
Methodology  (PODM)  that  extends  Carvalho  [4]  and 
speeifieally  addresses  the  evolution  of  requirements  into  an 
ontology  that  is  probabilistie  ally -integrated.  As  introdueed 
above,  a  probabilistieally -integrated  ontology  eombines  the 
inferential  reasoning  power  of  probabilistie  representations  with 
the  first-order  e^ressivity  of  ontologies.  A  key  eonponent  of 
that  methodology  is  a  detailed  Construetion  Proeess,  whieh 
e^lieitly  deseribes  the  iterative  tasks  required  to  produee  a 
probabilistie  ontology  with  in-situ  evaluation  steps  to  ensuie 
eontinuous  operation  for  inferential  reasoning.  Synergy 
aequired  through  the  use  of  the  PODM  allows  effieient, 
repeatable,  and  defensible  development  of  probabilistie 
ontologies. 

Traditional  ontologieal  engineering  faeilitates  the 
development  of  e^lieit,  logieal  and  defensible  ontologies  for 
knowledge-sharing  and  reuse.  This  researeh  delivers  a 
Probabilistie  Ontology  Development  Methodology  grounded  in 
Model-Based  Systems  Engineering  (MBSE)  prineiples.  Tasks 
as  soeiated  with  onto  logieal  engineering  and  the  inplementation 
of  probability  are  applieable  to  both  traditional  and  agile 
Systems  Development  Life  Cyele  (SDLC)  proeesses.  Within  an 
SDLC  framework,  exeeution  of  the  PODM  speeifieally 
addresses  the  evolution  of  requirements  into  an  ontology  that  is 
probabilistieally  integrated.  The  detailed  PODM  e^lieitly 
deseribes  the  iterative  tasks  required  to  produee  a  Probabilistie 
Ontology  (PO)  with  in-situ  evaluation  steps  to  ensuie 
eontinuous  operation  of  a  relational  model  produeed  for 
inferential  reasoning. 

B.  Terminology 

Before  delving  into  the  speeifies  of  the  PODM  it  is  neeessaiy 
to  elarify  terminology.  The  sinplified  definitions  below  are  used 
throughout  this  work. 


Taxonomy:  A  taxonomy  is  a  elassifieation  strueture  for 
ordering  objeets  into  eategories  [6]. 

Ontology:  An  ontology  is  an  e^lieit  speeifieation  of  a 
eoneeptualization  [7].  It  should  inelude  well-define  syntax  and 
semanties,  effieient  reasoning  support,  and  suffieient  egress ive 
power  [8]. 

Probabilistic  Ontology:  A  probabilistie  ontology  is  an 
e^lieit,  formal  knowledge  representation  that  egresses 
knowledge  about  a  domain  of  applieation,  ineluding  uneertainty 
about  all  forms  of  knowledge  [9]. 

Methodology:  A  methodology  is  a  eomprehensive, 

integrated  series  of  teehniques  or  methods  ereating  a  general 
systems  theory  of  how  a  elass  of  thought -intensive  work  ought 
to  be  performed  [10]. 

Process:  A  process  is  a  set  of  activities  that  collectively 
perform  a  function. 

Activity:  An  activity  is  a  constituent  undertaking  of  a 
process  [11]. 

Task:  A  task  is  the  smallest  unit  of  work  subject  to 
management  accountability  [2].  It  is  a  well-defined  work 
assignment  for  one  or  more  project  members.  Related  tasks  are 
grouped  to  form  activities  [11]. 

II.  Background 

The  Probabilistic  Ontology  Development  Methodology 
(PODM)  activities  span  the  phases  ofthe  Systems  Development 
Life  Cycle,  and  are  grounded  in  model-based  systems 
engineering  principles.  The  following  figures  demonstrate  how 
the  PODM  is  applicable  to  either  the  traditional  Waterfall 
Development,  or  the  Spiral  Development  Cycle.  Development 
phases  of  a  typical  Waterfall  SDLC  are  shown  in  Figure  1  [12]. 
The  color  codes  associated  with  these  phases  are  used 
consistently  through  the  remainder  of  this  work  to  aid  in  reader 
conprehension.  A  simple  probabilistic  ontology  model  may  be 
conpleted  using  a  single  pass  through  this  process. 

Coup  lex  development  problems  require  a  series  of  cycles  to 
bring  the  model  from  conceptualization  to  final  operation.  Spiral 
Development  is  suited  to  this  method  of  development,  with  each 
spiral  incorporating  Planning,  Analysis  &  Design,  Development 
&  Test,  and  Support  phases.  The  Waterfall  Development  phases 
introduced  in  Figure  1,  and  their  PODM-specific  tasks,  are 
overlaid  onto  a  Spiral  Development  Cycle  in  Figure  2 
[13][14][15][16]. 
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Figure  2  -  PODM  in  Spiral  Development  Cyele 


The  Spiral  Development  Cyele  phases  also  eorrespondto 
similar  phases  in  the  Unified  Proeess  (UP):  Ineeption, 
Elaboration,  Construetion,  and  Transition  [15].  The  PODM  is 
equally  applieable  to  all  three  development  proeess es,  as 
eapturedin  Table  1.  PODM  aetivities  are  speeified  in  the  left 
eolumn  and  their  mapping  to  the  three  proeess  es  is  defined 
within  eaeh  row.  Further  deseription  of  these  aetivities  is  given 
below.  The  Waterfall  proeess  is  eompleted  by  a  single  pass 
through  eaeh  of  the  development  aetivities  in  the  table,  top  to 
bottom  Both  Spiral  and  UP  proeess  es  perform  all  of  the 
development  aetivities  to  some  extent  in  eaeh  spiral,  as 
diseussed  below. 


The  remainder  of  this  work  assumes  a  Spiral  Development 
Cyele  is  ehosen  to  eomplete  development  of  the  probabilistie 
ontology.  Reeursion  is  prevalent  throughout  the  PODM.  To 
alleviate  eonfusion,  the  following  terms  are  applied  eonsistentfy 
throughout  the  remainder  of  the  work. 

Spiral:  A  spiral  deseribes  an  iteration  of  the  Spiral 
Development  Cyele.  Eaeh  spiral  has  a  unique  Objeetive 
Statement  and  one  or  more  supporting  Prime  Queries  deseribed 
below. 

Iteration:  An  iteration  deseribes  a  reeursive  step  within  the 
PO  Construetion  Proeess.  Iterations  e^and  the  Spiral  Core 
Model  by  deeonposing  its  attributes. 


Table  1  -  PODM  Development  Cyele  Alignment 


SDLC  Phase  [12] 

PODM  Activity 

Waterfall 

Spiral 

Unified  Process 

Frame 

Planning 

Analysis 

Design 

Plan 

Inception 

Analyze  &  Design 

Elaboration 

Ontology  Development 

Proba  bi  1  ity  1  ncorporation 
Refinement 

Evaluation 

Implementation 

Develop  &  Test 

Construction 

Operation 

Support 

Operate  &  Support 

Transition 
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III.  Overview  of  PODM  in  Spirae  Deveeopment 

A  probabilistic  ontology  developed  using  the  Spiral 
Development  Cycle  e>q)eriences  all  of  the  four  phases  in  each 
spiral.  While  the  first  spiral  has  the  heaviest  enphases  on 
Planning  and  Analysis  &  Design,  it  is  also  inportant  to  review 
and  update  these  phases  for  each  subsequent  spiral  to  ensure  the 
project  continues  to  be  aligned  to  the  Stakeholder  Decision 
Maker’s  objectives.  Within  the  PODM,  these  two  phases  are 
collectively  referred  to  as  the  Frame  Activity  because  they  frame 
the  scope  of  the  development  for  the  spiral.  The  Frame  Activity 
highlights  those  areas  in  the  Planning  and  Analysis  &  Design 
phases  that  are  updated  under  the  assumption  that  the 
management  tasks  remain  stable  throughout  development. 

Within  the  Develop  &  Test  Phase  of  the  Spiral  Development 
Cycle  a  Probabilistic  Ontology  Construction  Process  is 
incorporated  that  specifically  addresses  the  evolution  of 
requirements  into  an  ontology  that  is  probabilistically - 
integrated.  This  detailed  process  e>plicitly  describes  the 
iterative  tasks  required  to  produce  a  PO  with  in-situ  evaluation 
steps  to  ensure  continuous  operation  of  a  probabilistic  ontology 
produced  for  inferential  reasoning. 

The  Operate  &  Support  phase  enconpasses  fielding  and 
operation  of  the  system,  as  well  as  a  means  to  conduct  upgrades. 
Because  the  systemis  developed  iteratively,  the  systemwill  be 
in  operation  before  it  is  conplete  and  support  must  be  provided 
to  the  users. 

A.  Plan  Spiral  (Project  Planning  Phase  /  UP:  Inception) 

Planning  a  spiral  of  the  Spiral  Development  Cycle  is  a 
crucial  management  step  to  ensure  the  project  has  the  neeessaiy 
support  to  eonplete  the  spiral.  Before  the  first  spiral  is  begun, 
the  Stakeholder  Deeis ion  Maker  and  PO  Developer  eollaborate 
to  establish  the  overall  projeet  objeetive,  feasibility,  staffing 
support,  and  sehedule  [12].  This  is  the  projeet  launeh. 
Subsequently,  the  Planning  phase  only  requires  updates  to 
speeify  new  spiral  objeetives  and  their  assoeiated  sehedule 
revisions .  These  updates,  eombined  with  those  fromthe  Analyze 
&  Design  phase,  make  up  the  PODM  Frame  Aetivity.  Arguabty 
one  of  the  most  inportant  tasks  within  the  pre -launeh  Planning 
phase  is  seleetion  of  the  proper  representation  to  meet  the  overall 
objeetive  of  the  projeet. 

B.  Analyze  &  Design  (Analysis  and  Design  Phases  / 

UP:  Elaboration) 

The  Analyze  &  Design  phase  of  the  Spiral  Development 
Cyele  sets  the  stage  for  a  sueeessful  spiral  by  thorough^ 
researehing  and  doeumenting  supporting  information  to  aehieve 
the  spiral  objeetives  and  then  detailing  the  requirements  and 
metries  used  to  satisfy  and  measure  those  objeetives.  In  the 
Analysis  Phase,  researeh  is  eonduetedto  understand  the  problem 
domain  as  it  relates  to  the  projeet  objeetive,  ineluding: 
observation,  interview,  do eument  review,  and  existing  system 
review.  Satzinger  et  al.  suggests  prototyping  as  a  method  to 
understand  requirements  that  may  satisfy  spiral  objeetives  [12]. 
Partial  systems  represented  by  prototypes  provide  a  venue  for 
interaetion  with  the  Stakeholder  Deeis  ion  Maker  and  eventual 
users  to  elieit  requirements .  Information  gathered  throughout  the 
analysis  is  doeumented  for  ineorporation  into  the  solution. 


The  Design  Phase  enploys  Stakeholder  DM  input  and 
eolleeted  researeh  material  to  ereate  definitive  requirements  that 
the  solution  must  satisfy  to  meet  the  objeetives  of  the  spiral. 
Metries  are  developed  that  grade  these  requirements  to 
quantitatively  assess  performanee  against  the  requirements. 
Finally,  attributes  and  their  relationships  germane  to  the  spiral 
are  eolleeted  and  eaptured  in  a  elass  diagram  from  whieh 
development  begins . 

Combined  with  Planning  the  Spiral,  the  tasks  within  the 
Analyze  and  Design  phase  make  up  the  PODM  Framing 
Aetivity.  After  the  projeet  is  launehed,  subsequent  spirals  ofthe 
development  eyele  require  applieation  of  the  Framing  Aetivity 
to  ineorporate  appropriate  updates  from  these  phases. 

C.  Develop  &  Test  (Implementation  Phase/ UP: 
Construction) 

The  Develop  &  Test  Phase  ineludes  the  PODM  aetivities  of 
Ontology  Development,  Probability  Ineorporation  and 
Evaluation.  These  aetivities  eorrprise  the  heart  of  the  PODM  by 
defining  the  ontology,  adding  a  representation  ofuneertaintyand 
evaluating  the  model  against  requirements.  Two  reeursive 
eyeles  exist  within  the  Develop  &  Test  Phase.  The  first  eyele 
begins  with  a  sinple  probabilistie  model  that  is  inerementally 
e>q)anded  through  refinement  to  establish  a  probabilistie 
ontology  model  that  spans  the  entire  seope  of  the  deeision 
problem,  and  is  referred  to  as  the  Probabilistie  Ontology 
Construetion  Proeess.  The  seeond  eyele  involves  evaluation  of 
the  model  and  further  refinement  to  eorreet  logie  errors  and 
unantieipated  relationship  effeets . 


Figure  3  -  PODM  Construction  Process 


The  shaded  area  in  Figure  3  delineates  the  iterative  steps  of 
the  reeursive  PO  Construetion  Proeess.  During  both  initial  PO 
eonstruetion  and  updates  on  subsequent  spirals,  multiple 
eonstruetion  iterations  maybe  performed  to  ensure  eaeh  interim 
step  is  evaluated  for  valid  relationships  and  eorreet  logie. 
Similarly,  reeursion  exists  between  the  Evaluation  and 
Probability  Ineorporation  Aetivities.  Errors  diseovered  during 
the  Evaluation  Aetivity  prompt  refinement  of  the  model  for 
eorreetion.  These  in  turn  may  require  further  applieation  of  the 
Probability  Ineorporation  Aetivity. 
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Figure  4  -  Single  Iteration  of  the  PODM 


D.  Operate  &  Support  (Support Phase  /  UP:  Transition) 

The  Operate  &  Support  Phase  ineludes  three  major 
funetions:  maintenanee,  inprovement,  and  operational  support 
[12].  Maintenanee  and  operational  support  keep  the  eurrent 
build  in  serviee  and  enable  users  to  work  through  the  eontinuing 
development  proeess.  Inprovement  identifies  future  inerement 
eapabilities  that  will  be  ranked  for  prioritization  in  the  next 
Spiral  Development  Cyele.  Upgrades  ean  be  as  sinple  as 
adjusting  probabilistie  relationships,  or  as  eonplex  as  adding 
additional  evidential  nodes  to  the  overall  reasoning  proeess.  All 
require  some  level  of  iterative  refinement  and  evaluation  to 
ensure  model  logie  and  eonsisteney  are  maintained. 

IV.  Probabilistic  Ontology  Development 
Methodoeogy  Detaies 

The  above  phases  are  eombined  to  form  the  PODM  for  a 
single  spiral  of  the  development  eyele,  illustrated  in  Figure  4. 
The  remainder  of  this  seetion  delves  further  into  the  details  of 
the  PODM.  The  aetivities  of  the  PODM  and  their  tasks  are 
illustrated  in  Figures  5-8.  Conpletion  of  these  aetivities 
establishes  a  design  solution  to  a  speeifie  deeision  problem 
grounded  in  an  inelusive  ontology  representing  its  entities  and 
ineorporation  of  probability  to  represent  uneertainty.  A 
eonplete  deseription  of  eaeh  aetivity  and  its  eonponent 
subtasks  follows. 

A.  Frame  Activity 

For  eaeh  spiral  of  the  development  eyele,  the  Frame  Aetivity 
eneonpasses  neeessary  tasks  to  seope  the  problem  and  its 
requirements  based  on  the  Top-level  projeet  Objeetive 
Statement.  The  five  tasks  shown  in  Figure  5  eukninate  with  an 
initial  elass  diagram  that  is  used  to  identify  the  probabilistie 
relationships  of  the  Spiral  Core  Model  before  beginning  the 
Probability  Ineorporation  Aetivity. 


Figure  5  -  Frame  Aetivity 

Key  produets  of  the  Frame  Aetivity  inelude  an  Objeetive 
Statement  defining  the  overall  purpose  of  the  spiral,  one  or  more 


Prime  Queries  established  to  satisfy  the  objeetive  of  the 
Stakeholder  DM,  and  Tier-one  attributes  that  immediately  affeet 
the  Prime  Queries .  The  Prime  Queries  and  their  as  s  oeiated  Tier- 
one  attributes  define  the  Spiral  Core  Model  iterated  in  the  PO 
Construetion  Cyele  to  ereate  the  PO  used  for  inferential 
reasoning.  Supporting  and  informing  the  Spiral  Core  Model  are 
other  traditional  systems  engineering  produets  ineluding 
detailed  listings  of  requirements,  individuals,  andmetries. 

1 )  Frame  Activity  Tasks 

a)  Define  the  Spiral 

Defining  the  spiral  establishes  the  overall  objeetive  of  the 
spiral  and  identifies  the  Prime  Queries  that  satisfy  this  objeetive. 
Eaeh  spiral  of  the  development  eyele  has  a  single  objeetive  and 
oneormore  supporting  Prime  Queries.  Working  elosely  with  the 
Stakeholder  DM,  the  PO  Developer  erafl:s  the  Objeetive 
Statement  and  Prime  Queries,  as  well  as  eonstraints  on  the 
model  and  its  input  to  ereate  a  formal  definition  of  the  problem. 
Inferring  a  solution  to  the  Prime  Queries  is  the  reeurring  theme 
maintained  throughout  model  development. 

b)  Define  Requirements 

Ckady  defines  a  requirement  as  an  essential  attribute  for  a 
system  or  an  element  of  a  system,  eoupled  by  a  relation 
statement  with  value  and  units  information  for  the  attribute  [17]. 
Using  either  a  top-down,  bottom-up,  or  middle -out  proeess, 
requirements  are  elieited  that  ensure  satis faetion  of  the  spiral 
Objeetive  Statement  and  eaptured  in  a  Requirements  Table.  The 
goal  of  this  taskis  to  eapture  attributes  that  should  be  eontroUed 
within  the  model  in  written  requirement  statements,  to  be 
validated  by  the  Stakeholder  DM  and  measured  by  the  metries. 
Several  methods  of  requirement  elieitation  are  available  in  the 
literature. 

c)  Define  Metrics 

Metries  are  parameters  or  measures  of  quantitative 
assessment  used  for  measurement,  eorrparison  or  to  traek 
performanee  of  the  requirements  against  some  benehmark 
established  in  eollab oration  with  the  Stakeholder  DM.  An  initial 
set  of  metries  based  on  the  requirements  defined  to  support  the 
spiral  objeetive  is  developed  and  eaptured  in  a  Metries  Table.  It 
is  best  if  there  is  at  least  one  metrie  to  support  eaeh  requirement 
of  the  system.  Metries  that  do  not  support  a  requirement,  either 
direetly  or  indireetly,  should  be  pruned  from  the  metries  table. 
Armstrong  defines  a  useful  metrie  as  one  that  takes  a 
quantifiable  form  with  a  elear  definition  of  the  measure  and 
assoeiated  units  [18].  The  metries  may  be  in  the  form  of  a 
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confidence  interval  or  a  percentage  of  correct  responses  given  a 
defined  amount  of  information,  or  other  suitable  measurement. 

d)  Identify  Tier-one  Attributes 

Attributes  immediately  affecting  the  Prime  Queries  establish 
the  minimal  probabilistic  model  that  will  support  the  decision  of 
interest,  and  are  referred  to  as  Tier-one  attributes.  They  form  the 
core  of  the  probabilistic  ontology  mo  del  and  are  e^andedupon 
in  thePO  Construction  Process  to  conplete  the  entire  inference 
network.  The  initial  class  diagram  is  created  from  these  Tier-one 
attributes  and  the  Prime  Queries.  The  following  steps  lead  to 
identification  of  the  Tier-one  attributes: 

Based  on  the  Prime  Queries,  identify  the  class  of  objects 
about  which  the  reasoning  will  occur. 

Identify  relationships  that  immediately  affect  the  Prime 
Queries.  These  are  the  Tier-one  attributes.  Causal relationshps 
are  established  by  identifying  variables  thatmay  cause  a  variable 
to  take  a  particular  state  or  prevent  it  from  taking  a  particular 
state  [19]. 

At  the  most  general  level,  identify  the  classes  that  are 
affected  by  these  relationships.  The  established  relationshps 
and  classes  populate  the  initial  class  diagram 

e)  Draft  Initial  Class  Diagram 

The  initial  class  diagram  enables  the  PO  Developer  to 
visualize  and  communicate  the  relationships  directly  affecting 
the  Prime  Queries  via  the  Tier-one  attributes .  Later,  this  diagram 
is  iteratively  extended  in  the  PO  Construction  Process  to  include 
all  attributes  and  relationships  in  a  systematic  and 
conprehensive  fashion.  The  class  diagram  shows  classes  and 
subclasses  of  objects  that  are  instantiated  in  the  model.  As  this 
is  the  initial  class  diagram,  clarity  is  of  great  importance 
necessitating  the  inclusion  of  both  cardinality  and  relationshp 
information. 

2)  Frame  Activity  Products 

a)  Objective  Statement 

There  are  two  types  of  objective  statements  enployed  in  this 
development  process.  The  Top-level  Objective  Statement 
describes  the  overall  purpose  of  the  PO  in  a  manner 
understandable  to  both  the  Stakeholder  DM  and  the  PO 
Developer.  The  Spiral  Objective  Statements  identify  the  purpose 
of  each  specific  spiral  and  should  support  the  Top-level 
Objective.  Both  should  be  specific,  concise,  and  observable. 

b)  Prime  Query 

A  Prime  Query  defines  a  principal  area  of  focus  for 
development  in  the  spiral  in  the  form  of  a  question.  The 
inference  network  seeks  to  answer  this  question  at  the 
conpletion  of  the  Develop  &  Test  Phase. 

c)  Requirements  Table 

The  Requirements  Table  captures  the  validated  requirements 
that  represent  behaviors,  applications,  constraints,  properties, 
and  attributes  that  directly  support  the  Spiral  Objective 
Statement.  The  table  should  include  a  title  and  brief  descriptive 
statement  for  each  requirement.  Requirements  definition 
requires  close  collaboration  between  the  PO  Developer,  the 


Stakeholder  DM,  SMEs  and  users.  The  literature  describes 
several  methods  for  elicitation  of  requirements. 

d)  Individuals  Table 

Each  class  within  the  ontology  contains  individuals  that  are 
specific  to  the  domain  of  interest.  However,  the  same  model 
could  be  enployed  for  inferential  reasoning  support  fora  similar 
problem  in  the  same  domain.  The  PO  will  access  the  individuals 
instantiated  in  the  ontology  in  response  to  a  query  to  produce  an 
inference  result-  typically  a  probability  distribution  on  different 
answers  to  the  query.  A  limited  set  of  instances  is  used  to 
demonstrate  feasibility  ofthe  methodology  without  stressing  the 
software  application.  The  final  operational  application  of  an 
ontology  may  have  hundreds  of  instances. 

e)  Metrics  Table 

Through  eperience  and  stakeholder  elicitation, 
performance  goals  and  their  associated  metrics  may  be 
identified  and  captured  for  use  in  model  evaluation.  Many 
methods  exist  to  elicit  relevant  metrics  for  a  given  domain. 
Armstrong  proposes  a  brainstorming  process  during  which  rows 
ofthe  metrics  table  are  elicited  by  eperts  using  the  requirements 
table  as  a  map  [18].  These  metrics  are  used  to  validate  the  spiral 
model  against  its  requirements. 

f)  Tier -one  Attributes 

As  previously  introduced,  the  Tier-one  Attributes  have 
immediate  effect  on  the  Prime  Queries  for  the  spiral  by  virtue  of 
their  immediate  proximity.  The  Tier-one  Attributes  are  also  the 
nearest  neighbors  to  the  Prime  Queries’  classes  in  the  initial 
class  diagram  Cementing  the  Spiral  Core  Model  through 
thoughtful  determination  ofboth  the  Prime  Queries  and  Tier-one 
Attributes  ensures  a  model  that  is  both  relevant  and  coherent, 
meeting  the  Spiral  Objeetive. 

g)  Initial  Class  Diagram 

The  Initial  Class  Diagram  establishes  the  eore  of  the 
probabilistie  ontology  model  and  is  iteratively  e>q)anded  in  the 
PO  ConstruetionProeess  to  ineorporate  the  full  speeifieation  of 
requirements.  At  this  point,  known  related  elasses  may  be 
ineluded  as  attributes  of  Tier-one  Attribute  elasses  to  elarify  how 
this  elass  diagram  is  to  be  e^anded. 

B.  Ontology  Development  Activity 

An  ontology  is  used  to  eapture  eons ensual knowledge  about 
a  domain  of  interest  [2].  The  Ontology  Development  aetivity 
summarizes  the  non-trivial  ontologieal  engineering  tasks 
required  to  produee  a  working  ontology,  shown  in  Figure  6. 
Seleetion  of  the  appropriate  ontologieal  engineering 
methodology  is  eontext  dependent  as  is  the  required  fidelity  of 
the  ontologieal  model.  However,  there  are  tasks  and  produets 
eommon  to  eaeh  of  these  proeesses  summarized  in  Figure  6  and 
diseussed  below. 
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Figure  6  -  Ontology  Development  Aetivity 


1)  Ontology  Development  Activity  Tasks 

a)  Conduct  Ontological  Engineering 

Gomez-Perez  et  al.  define  ontologieal  engineering  as  the  set 

of  aetivities  that  eoneem  the  ontology  development  proeess,  the 
ontology  life  eyele,  and  the  methodologies,  tools,  and  languages 
for  building  ontologies  [2].  With  a  elear  understanding  of  the 
spiral  objeetive  and  requirements,  ontology  eonstruetion begins 
following  one  of  the  eommunity-aeeepted  ontologieal 
development  proeess es  deseribed  by  Gomez-Perez  et  al.  [2]. 
Eaeh  of  these  methodologies  ineludes  both  management  and 
development  aetivities  to  produee  ontologies  from 
eoneeptualization  to  implementation.  In  general,  the  proposed 
methods  identify  the  tasks  that  need  to  be  performed  without 
regard  for  the  order  in  whieh  they  are  eompleted.  The  goal  of  the 
Ontology  Development  Aetivity  is  to  produee  a  working 
ontology  that  aeeurately  represents  the  relationships  of 
inportanee,  foeusing  on  the  Prime  Queries . 

Terms  and  proeesses  for  development  are  as  various  as  the 
applieation  for  whieh  they  are  used.  A  generalized  sequeneeof 
steps  iteratively  modeled  for  ontologieal  engineering  is 
proposed  below  as : 

Ontological  Engineering  Process 

Identify  what  objects  are  acting  or  acted  upon? 

Develop  Context:  where  or  when  are  the  actions  occurring? 
Identify  Relationships:  what  objects  are  affected? 

Identify  States:  in  what  condition  may  an  object  be  found? 

Many  of  these  steps  are  initialized  in  the  Frame  Aetivity  and 
are  eontinued  here  in  the  Ontology  Development  Aetivity. 
Through  eontinuous  refinement,  elasses,  eontext,  relationships, 
and  states  will  be  fully  identified  and  ready  for  modeling  within 
an  appropriate  software  paekage. 

b)  Research  Usable  Ontologies 

Before  beginning  eonstruetion  ofthe  ontology,  it  is  usefulto 
researeh  existing  ontologies  in  related  domains  to  be  reused 
and/or  extended  for  the  eurrent  problem.  Modelreuseis  defined 
as  the  proeess  by  whieh  available  knowledge  is  used  as  input  to 
generate  new  models.  Reusing  existing  models  may  also  require 
ontologieal  re-engineering  as  deseribed  by  Gomez-Perez  et  al. 
[2].  Similarly,  ontology  merging  is  a  proeess  by  whieh  a  unique 
ontology  is  derived  from  two  or  more  existing  ontologies.  Theie 
is  an  existing  andever-inereasing  body  of  knowledge  regarding 
model  reuse  and  extension  that  is  beyond  the  seope  of  this  work 
and  ineludes  methods  sueh  as  ONIONS,  FCA-Merge,  and 


PROMPT.  The  interested  reader  may  find  these  teehniques  in 
Gomez-Perez  et  al.  [2]. 

c)  Research  Heuristics  and  Algorithms 

A  heuristie  is  an  eperienee -based  teehnique  for  problem 
solving,  learning,  and  diseovery;  an  algorithm  is  a  stepwise 
proeedure  for  ealeulation  of  a  problem  solution.  Heuristies  and 
algorithms  are  used  to  QspvQss  relationships  between  elasses  and 
individuals  within  ontologies  and  probabilistie  ontologies.  For 
the  Ontology  Development  Aetivity,  these  heuristies  and 
algorithms  are  used  as  bounding  eonstraints  to  seope  the  model 
appropriately  for  the  domain  by  eapturing  plain -language 
relationship  statements  in  maehine -readable  format.  Relevant 
heuristies  and  algorithms  are  regarded  as  Axioms  whieh  are 
propositions  assumed  without  proof  for  the  sake  of  studying  the 
eonsequenees  that  follow  from  it  [20].  They  are  eaptured  in  a 
Formal  Axiom  &  Rules  Table  for  ineorporation  into  the  spiral 
model. 

d)  Implement  Ontology  Model 

At  this  point  the  ontology  is  inplemented  in  a  suitable 
ontology  building  environment  and  evaluated  for  eonsisteney 
using  an  appropriate  evaluation  methodology  fromthe  literature, 
eonstruetion  tools  sueh  as  Protege,  Ontolingua,  and  OntoFdit 
aid  in  the  key  tasks  of  ontology  inplementation,  eonsisteney 
eheeking,  and  doeumentation  [2].  Protege  is  based  on  the 
Frames  eonstruet  and  supports  first-order  logie  reasoning  [2] 
[21]. 

e)  Ontological  Learning  Activity 

There  are  several  methods  to  aid  in  the  knowledge 
aequisition  proeess  required  to  build  an  ontology.  These  inelude, 
but  are  not  limited  to  ontologieal  learning  from  texts,  ontologieal 
learning  from  instanees,  ontologieal  learning  from  sehemata, 
and  ontologieal  learning  for  interoperability.  Use  of  these 
teehniques  may  aid  in  ontology  development.  The  interested 
reader  will  also  find  further  information  on  these  topies  in 
Gomez-Perez  et  al.  [2]. 

2)  Ontology  Development  Activity  Products 

The  Ontology  Development  aetivity  produees  five  produets 
used  to  perform  the  Probability  Ineorporation  Aetivity  of  the 
PODM,  as  shown  in  Figure  6  above.  While  eorrpletion  of  the 
PODM  is  feasible  without  these  produets,  they  provide 
signifieant  aid  in  the  doeumentation  of  the  PO  and  reduee  the 
likelihood  of  error  during  the  iterative  PO  Construetion  Proeess. 

a)  Taxonomy  and  Relationships 

A  taxonomy  is  used  to  organize  entity  elasses  and  instanees 
through  a  hierarehieal  framework  based  on  shared 
eharaeteristies  and  serves  as  a  baseline  blueprint  for  the  ontology 
framework.  Objeets  are  ordered  into  elasses  to  define  attribute 
inheritanee  and  inter-elass  relationships.  For  this  applieation,  the 
taxonomy  eaptures  a  eonplete  dietionary  of  the  aetors  in  a 
natural  relationship  format.  Relationships  between  elasses  in  the 
ontology  are  deseribed  by  objeet  properties . 

b)  Class  Table 

The  Class  Table  eaptures  the  attributes  and  relations  that 
deseribe  all  of  the  elasses  in  the  ontology.  For  eaeh  elass  the 
objeet  properties,  data  properties,  and  their  as soeiated  relations. 
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domains,  and  ranges  are  eolleeted.  This  eonpilation  is  used  as  a 
ready -referenee  throughout  the  ontologieal  engineering  proeess 
and  aids  the  developer  in  maintaining  eonsisteney.  A  eoneise 
Class  Table  allows  inplementation  of  the  ontology  in  one  of 
several  ontologieal paekages  introdueed previously. 

c)  Complete  Class  Diagram 

Class  diagrams  are  a  mainstay  of  objeet -oriented  analysis 
and  design.  They  identify  the  hierarehy  of  variables  germane  to 
the  model.  Relationships  between  variables  that  eould  eause 
another  variable  to  ehange  states  are  highlighted  to  eaptuie 
eausality  between  elasses.  Typieally  elass  diagrams  show  the 
elasses  of  the  system,  their  interrelationships  (ineluding 
inheritanee,  aggregation,  and  assoeiation),  and  the  operations 
and  attributes  of  the  elasses. 

d)  Formal  Axioms  and  Rules  Table 

Formal  Axioms  are  first-order  logieal  expressions  that  are 
always  true.  Rules  are  used  to  infer  attribute  values,  or  relation 
instanees  [2].  The  Formal  Axioms  and  Rules  Table  also  eaptuies 
heuristies  and  algorithms  that  aet  as  eonstraints  for  the  model. 
The  entries  in  this  table  transform  plain  language  eonstraints  into 
formal,  maehine  proeess  able  form. 

e)  Operational  Ontology 

Finally,  the  operational  ontology  is  ereated  and  is  ready  for 
evaluation.  When  seeking  to  answer  a  query  about  a  speeifie 
domain  of  interest,  the  ontology  ean  be  eonsidered  a  eonpilation 
of  voeabulary  and  eoneepts  used  to  frame  the  related  entities. 
Reeall  from  Qnber, 

“An  onto  I  ogy  is  an  exp  li  cit  specification  of  a  conceptual  ization 

[IV 


The  working  ontology  serves  as  the  relational  framework  for 
the  PO  when  uneertainty  is  introdueed.  Construetion  tools  and 
environments  sueh  as  Protege  aid  in  the  key  ontologieal 
engineering  tasks  of  inplementation,  eonsisteney  eheeking,  and 
doeumentation. 

C.  Probability  Incorporation  Activity 

The  Probability  Ineoporation  Aetivity  is  the  heart  of  the 
PODM,  illustrated  in  Figure  7.  Eaeh  spiral  of  the  development 
eyele  begins  with  ereation  of  a  Spiral  Core  Model  based  on  the 
Prime  Queries  and  their  Tier-one  attributes,  as  shown  in  the 
figure.  The  Spiral  Core  Model  is  the  keystone  of  development 
and  is  evaluated  for  eorreet  operation  and  logie  before  the  model 
is  expanded  to  inelude  additional  attributes.  After  the  Spiral 
Core  Model  generation  tasks,  the  iterative  PO  Construetion 
Proeess  systematieally  deeonposes  eaeh  of  the  primary, 
seeondary  and  tertiary  attributes,  evaluating  model  logie  at  eaeh 
step. 

The  PODM  has  been  tested  using  Multi-Entity  Bayesian 
Networks  to  model  a  PO  eaptured  in  the  UnBBayes  software 
tool.  A  MEBN  represents  knowledge  about  attributes  of  entities 
and  their  relationships  as  a  eolleetion  of  similar  hypotheses 
organized  into  theories,  whieh  satisfy  eonsisteney  eonstraints 
ensuring  a  unique  joint  probability  distribution  over  the  random 
variables  of  interest  [9].  MEBN  Theories  ean  represent 
uneertainty  about  values  of  n-ary  ftmetion  and  relations. 
UnBBayes  is  open  souree  software  for  modeling,  learning  and 
reasoning  upon  probabilistie  networks  [22][23][24].  In  the 
following  seetions,  illustrations  of  appropriate  MEBN 
eonponents  eaptured  in  the  UnBBayes  software  tool  are 
provided  for  elarifieation. 


Figure  7  -  Probability  Incorporation  Activity  andPO  Construction  Process 
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1)  Core  Mo  del  Gen  eratio  n 

The  initial  PODM  steps  for  ineorp  oration  of  probability  set 
the  framework  for  the  eonplete  model  and  establish  the  spiral 
Prime  Queries  that  will  be  servieed  through  the  inferential 
reasoning  model.  The  Core  Model  is  established  based  on 
attributes  immediately  affeeting  the  spiral  Prime  Queries, 
referred  to  as  Tier-one  attributes .  Next,  the  Loeal  Probability 
Distributions  (LPDs)  of  this  Core  Model  are  populated  with 
proxy  probabilities  that  test  the  logie  of  the  model  without 
ereating  all  of  the  related  braneh  nodes  resident  in  the  final 
model.  The  proxy  probabilities  should  be  representative  of 
e>q)eeted  posterior  likelihoods  delivered  by  individual  Bayesian 
network  branehes  under  a  eonpleted  model.  The  model  is  then 
exeeuted  and  the  logie  examined.  At  this  stage  of  development, 
errors  are  usually  eaused  by  illogieal  LPD  values  sinee  the 
model  arehiteeture  is  quite  sinple.  Establishing  a  strong 
foundation  in  this  fashion  eases  debugging  when  the  eonplexity 
of  the  model  inereases. 

The  PO  ConstruetionProeess  Iteration  Plan  ( 

Figure  9)  shows  how  the  Spiral  Core  Model  for  the  first  spiral 
of  the  development  proeess  fora  Military  Ship  PO  is  expanded 
to  satisfy  the  Objeetive  Statement.  The  first  iteration  of  the  PO 
Construetion  Proeess  introduees  uneertainty  assoeiated  with  the 
arrival  of  reports  about  the  size  of  the  eontaet  of  interest.  Next, 
Iteration  2  expands  the  model  to  inelude  uneertainty  from  the 
arrival  of  reports  about  the  type  of  warship  observed.  Finally, 
Iteration  3  adds  detail  based  on  the  sensors  and  weapons 
required  to  eonplete  the  Primary  Mission  tasked  to  a  given 
elass. 

Upon  eompletion  of  the  third  iteration  of  the  PO 
Construetion  Proeess,  a  detailed  model  of  the  first  spiral  is 
eonplete  whieh  provides  an  inferred  solution  to  the  first  spiral 
Prime  Queries  in  the  faee  of  uneertainty. 

a)  Create  Model  of  Prime  Queries  and  Tier-one  Attributes 


The  spiral  Prime  Query  model  is  populated  with  eonditional 
probabilities  based  on  the  Tier-one  attribute  relationships.  LPDs 
for  Prime  Query  nodes  should  have  aetual  eonditional 
probabilities.  However,  the  Tier-one  attribute  LPDs  usepro^ 
values  allowing  testing  of  the  Spiral  Core  Model  logie  before  the 
model  is  iterated  in  the  PO  Construetion  Proeess.  The  first  two 
steps  of  the  Probability  Ineorporation  Aetivity  produee  the 
Spiral  Core  Model,  eaptured  in  the  sinple  MEBN  below  (Figure 
8). 


Eaeh  of  the  Tier-one  Attributes  of  the  Prime  Query  is 
represented  by  a  MEBN  Fragment  (MFrag),  and  provides  input 
to  the  Prime  Query  MFrag. 

b)  PopulateLPD  with  Proxy  Values 

The  LPD  of  the  Tier-one  attribute  nodes  are  populated  with 
values  that  allow  testing  of  the  eore  model  before  all  of  the 
relationships  are  in  plaee.  The  Tier-one  LPDs  use  proxy  values 
representing  full  network  eonneetivity,  and  the  Prime  Query 
LPD  is  populated  with  appropriate  eonditional  probabilities. 


I _ j 

Iteration  3 

Figure  9  -  PO  Construction  Process  Iteration  Plan 
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a)  Execute  Model  and  Evaluate  Logic 

Using  the  software  tool,  the  model  is  exeeuted  with  test 
evidenee.  It  is  useful  to  ereate  a  sinple  model  using  a  Bayesian 
network  software  paekage  to  eonpare  testing  values.  The  simple 
exanples  used  in  the  tutorial  show  that  the  Spiral  Core  Model 
logie  operates  eorreetly,  and  the  knowledge  engineer  ean  be 
eonfidentin  moving  forward  with  the  PO  ConstruetionProeess. 


Figure  10  -  Netica  Bayesian  Network  to  Test  Core  Model 


The  Bayesian  network  in  Figure  10  was  ereated  using  the 
Netiea  [25]  software  tool  and  verifies  the  logie  of  the  sinple 
SSBN.  This  proeess  of  querying  the  probabihstie  ontology 
model  and  evaluating  the  model  eontinues  throughout  the 
iterative  development  proeess. 

b)  Probabilistic  Learning  Activity 
Probabihstie  learning  uses  a  relational  sehema  assumed  by 
the  elasses,  their  attributes,  and  relationships  between  e lasses  to 
reduee  the  effort  involved  in  estabhshing  prior  and  eonditional 
probabihties  for  domain  entities.  A  training  set  in  the  form  of  a 
relational  database  of  enpirieal  data  is  utilized  and  the  LPD 
parameters  are  determined  using  the  likelihood  ftmetion  and  an 
appropriate  algorithm  (e.g.  Maximum  Likelihood  Parameter 
Estimation  or  Bayesian  Parameter  Estimation)  [26]. 

2)  Probabilistic  Ontology  Construction  Process 
The  iterative  steps  follow  the  PO  Construetion  Proeess, 
shown  in  Figure  7  above,  to  systematieaUy  expand  the  initial 
model  while  ensuring  eoherent  logie  is  maintained.  In  eaeh 
iteration,  a  related  elass  is  seleeted  and  deeomposed  into  its 
immediate  sub-elasses  and  their  attributes.  A  representation  is 
ereated  for  the  related  elass,  and  LPDs  are  populated  with  pro>^ 
probabihties  for  the  attributes  if  the  node  is  non-terminal. 
Otherwise,  appropriate  prior  probabihties  are  established  in  the 
LPD  through  researeh  or  Subjeet -Matter  Expert  elieitation. 
Next,  the  model  ereated  in  previous  steps  is  updated  to  inelude 
relationships  with  the  newly  ereated  representation,  and  the 
LPDs  are  updated  to  eapture  any  probabihstie  relationships .  The 
final  step  in  the  iteration  is  to  exeeute  the  model  and  evaluate  its 
logie  using  example  data.  Logie  errors  at  this  stage  are  likely 
eausedby  oversights  and  errors  in  the  update  of  the  existing 
model.  When  the  exeeuted  model  produees  the  desired  logie,  the 
next  iteration  is  begun.  The  PO  Construetion  Proeess  is 
summarized  as: 


PO  Construction  Process 

i.  Seleet  and  deeonpose  a  related  elass  into  its  sub-elasses 
and  attributes 

h.  Create  a  representation  for  the  seleeted  related  elass 
hi.  Populate  LPDs  of  related  elass  attributes 
iv.  Update  existing  model  relationships  and  LPDs 
V.  Exeeute  model  and  evaluate  logie 

a)  Select  and  Decompose  a  Related  Class  into  its 
Sub-classes  and  Attributes 

One  of  the  related  elasses  identified  from  the  elass  diagram 
is  deeomposed  into  its  subeomponents,  elasses  and  attributes. 
The  sub-elasses  should  be  deeonposed  to  the  lowest  possible 
level. 

b)  Create  a  Representation  for  the  Selected  Related 
Class 

Using  the  information  assembled  in  the  deeonposition,  build 
a  representation  for  the  new  elass.  Addition  of  a  elass  influenees 
one  or  more  existing  elasses.  Summarizing  the  relevant 
properties,  domain,  range  and  variables  sinphfies  produetionof 
the  model  and  diseovery  model  logie. 

In  the  MilShip  PO,  the  UnBBayes  MEBN  MFrag  for  the 
Ship  Size  is  shown  above  (Figure  II).  Input  Nodes  for  the  Ship 
Displaeement  and  Ship  Length  attributes  are  added  to  the  MFmg 
to  eapture  uneertainty  for  these  properties  as  diseussed  above. 
Further,  the  aetual  ship  size  direetly  affeets  the  Reported  Size  as 
ean  be  seen  below.  The  Reported  Size  is  binned  into  the  same 
three  possible  eategorieal  states  as  the  original  Ship  Size 
variable  (small,  medium,  large). 

a)  Populate  LPDs  of  Related  Class  Attributes 
LPDs  for  the  new  nodes  may  be  in  the  form  of  a  eonditional 
probability  table.  (CPT)  or  logie  statements,  depending  on  the 
probabihstie  ontology  software  utilized.  If  further 
deeonposition  is  warranted,  proxy  values  should  be  used  forthe 
nodes  similar  to  those  of  the  Tier-one  Attributes  above. 
Otherwise,  terminal  node  likelihoods  should  be  established  via 
researeh  or  SME  eheitation. 

a)  Update  Existing  Model  Relationships  and  LPDs 

All  legaey  nodes  affeeted  by  addition  of  the  new  attribute 
must  be  updated  to  refleet  eonditional  probabilities  eN^ressing 
the  relationships  assoeiated  with  the  new  node.  Elieitation  of 
eonditional  probabilities  within  the  LPD  is  aeeonplished 
through  researeh,  SME  interview,  or  Bayesian  learning 
teehniques.  A  simplified  Bayesian  network  may  also  aid  thePO 
Developer  in  elieiting  the  prior  values  to  use  in  this  statement. 
The  updated  LPD  provides  a  more  reahstie  illustration  of  the 
uneertainty  of  judging  dimensions  with  the  addition  of  the  size 
parameter  nodes.  By  foeusing  on  a  single  attribute  at  a  time, 
mistakes  in  updating  logie  are  minimized  and  eohereney  is 
maintained  as  the  model  beeomes  inereasingly  eonplex 

a)  Execute  the  Model  and  Evaluate  Logic 
After  eaeh  iteration  of  the  PO  Construetion  Proeess  is 
eonplete,  the  model  is  exeeuted  toprodueean  inferred  solution 
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Figure  1 1  -  Ship  Size  MFrag  (Iteration  1) 


Figure  12  -  Completed  MilShip  PO  MTheory 


to  a  Prime  Query.  A  sinple  test  is  devised  that  introduees 
evidenee  to  the  updated  relationships  to  ensure  model  logie  was 
maintained  through  the  update.  When  feasible,  it  is 
advantageous  to  eonpare  an  instantiation  with  the  appropriate 
Bayesian  network  model,  as  previously  diseussed.  A  sinple  test 
ease  should  be  suffieient  to  ensure  that  the  logie  is  performing 


as  epeeted;  more  elaborate  test  eases  are  used  in  the  Evaluation 
Aetivity. 

Three  iterations  of  the  model  are  eonduetedto  eonplete  the 
first  spiral  of  the  Military  Ship  PO  as  shown  in 

Figure  9  and  diseussed  above.  The  eompleted  MTheory 
model  is  shown  in  Figure  12. 
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Evidence  of  the  iterative  process  is  clear  in  the  above  figure. 
First,  note  that  hasShipSize  is  conditional  on  hasShipDisp  and 
has  Ship  Length,  which  correspond  to  input  parameters. 
hasRptSize  is  conditional  on  hasShipSize  indicating  that  a 
reported  size  is  dependent  on  actual  size.  Next,  hasRptXype  is 
conditional  on  hasWarshipType,  demonstrating  that  a  type 
report  is  affected  by  the  actual  type  of  warship  observed. 
Similarly,  has  Primary  Msn  is  conditional  on  hasWarshipType, 
indicating  that  certain  warship  types  have  associated  likelihoods 
of  conducting  specific  missions.  Finally,  both  has ShipSensor 
and  hasWeapon  are  conditional  on  has  Primary  Msn,  indicating 
that  missions  require  specific  types  of  weapons  and  their 
associated  sensors.  The  hasWeapon  variable  is  also  conditional 
on  hasWarshipType  because  not  all  types  of  warships  carry 
every  type  of  weapon. 

D.  Evaluation  Activity 

The  Evaluation  Activity  conpletes  the  PODM  as  shown  in 
Figure  13  by  two  methods.  First,  an  elicitation  review  is 
conducted  by  the  PO  Developer  and  SMEs .  Then,  a  s  equence  of 
increasingly  difficult  test  cases  is  applied  to  test  the  model  across 
the  spectrum  of  e>q)ected  performance.  Results  are  evaluated 
against  existing  models  or  by  the  development  team  A  case  that 
results  in  erroneous  logic  is  returned  to  the  PO  Constructbn 
Process  at  the  deconpositiontaskto  rebuild  the  representation. 
A  successfulcaseis  documented  and  followed  by  the  next  case 
study. 


1)  Conduct  Elicitation  Review 

An  elicitation  review  is  a  holistic  review  of  the  probabilistic 
ontology  to  ensure  it  is  consistent  with  the  spiral  objective  and 
Top-level  Objective  Statement.  Laskey  and  Mahoney  describe 
the  elicitation  review  as  an  overall  review  of  node  definitions, 
state  definitions,  independence  assunptions,  and  probability 
distributions  [27].  This  is  a  qualitative  assessment  provided  by 
e>q)ert  reviewers  including  the  Stakeholder  DM,  SMEs,  and 
users. 

2)  Draft  Case  Studies 

A  series  of  increasingly  conplex  test  cases  is  developed  to 
test  model  logic  and  coherence  in  an  operational  context.  Test 
cases  are  designed  to  test  the  spectrum  of  inference  tasks 
expected  to  be  encountered  during  operations  within  the  Operate 
&  Support  Phase  of  the  SDLC.  Theconplete  set  of  cases  should 
fully  examine  the  model  and  specify  assunptions,  input 
parameters,  and  ejected  output.  Evidence  collected  throughout 
the  modeling  process  and  captured  within  the  model  may  be 


useful  in  formulating  these  cases.  Each  testcaseis  evaluated  in 
the  spiral  PO  and  evaluated  by  expert  reviewers.  Deficiencies 
are  meticulously  documented  to  aid  in  model  correction. 

3)  Populate  Evidence  Variables 

For  each  case  study,  the  appropriate  evidence  is  incorporated 
into  thePO  model  using  FOE  statements. 

4)  Run  PO  Model  and  Evaluate  Results 

Once  all  of  the  evidence  for  the  case  is  loaded  into  the  PO 
KB,  the  Prime  Queries  are  executed  and  PO  results  are  evaluated 
by  e^ert  reviewers  to  identify  potential  logical  or  relation shp 
errors.  Cases  producing  incorrect  results  return  to  the  PO 
Construction  Process  for  refinement  (Figure  7  and  Figure  13).  A 
test  case  that  performs  as  expected  is  documented,  and  the  next 
testcaseis  applied. 

5)  Correct  Model  as  Required  via  PO  Construction 
Process 

Logical  and  relational  errors  necessitate  a  return  to  PO 
Construction  Process,  as  discussed  above.  A  review  of  the  model 
should  identify  which  sub -class  or  attribute  representation  is 
causing  the  error,  thereby  focusing  the  correction.  The  PO 
Construction  Process  is  re-run  for  that  related  class  beginning 
with  task  two  (Create  representation  for  selected  class)  and 
conpleted  through  task  five.  Upon  successful  creation  and 
evaluation  of  the  executed  model,  the  Evaluation  Activity  is 
resumed. 

E.  Support  Activity 

As  introduced  in  Section  III.D,  the  Operate  &  Support  Phase 
of  the  SDLC  includes  three  functions:  maintenance, 
inprovement,  and  operational  support  [12].  In  the  context  of  the 
PODM,  inprovement  is  the  germane  task  in  this  set.  Once  the 
PO  is  inplemented  and  operating,  periodic  updates  may  be 
desired.  Sinple  refinements  of  relationships  enter  the  PO 
Construction  Process  at  task  two  (Create  representation  for  the 
selected  related  class).  From  this  point  the  process  proceeds  with 
one  or  more  iterative  cycles,  until  the  modification  is  conplete. 
More  elaborate  inprovements  are  assigned  to  a  prioritized 
update  list  for  entry  into  planning  for  the  next  spiral  in  the 
SDLC.  This  type  of  update  receives  the  full  PODM  process. 
Inprovements  must  be  followed  by  an  evaluation  to  ensuie 
continued  model  functionality. 

V.  Summary 

The  Probabilistic  Ontology  Development  Methodology 
provides  a  specific,  guided  methodology  to  inplement  the 
reference  architecture  introduced  in  [28].  It  is  widely  applicable 
across  multiple  systems  development  process  styles  and 
ontological  domains.  In  the  following  chapter,  the  efficiency, 
effectiveness  and  teachability  of  the  PODM  are  demonstrated 
through  a  user  case  study. 

A.  Applicability 

The  Probabilistic  Ontology  Development  Methodology  is 
applicable  across  the  spectrum  of  ontology  domains  where 
representation  of  uncertainty  is  required.  Meticulous,  structuied 
deconposition  of  coup  lex  problems  ensures  relationships  are 
established  and  updated  while  maintaining  model  logic.  The 
methodology  supports  development  of  a  PO  from 
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conceptualization  to  operation,  but  the  PODM  is  equally  useful 
incorporating  and  testing  uncertainty  into  an  existing  ontology. 

B.  Scalability  of  the  PODM 

The  PODM  is  scalable  to  ontologies  of  varying  sizes  by 
deconposing  the  model  into  manageable  tasks  or  conducting 
multiple  iterations  of  a  Spiral  Development  Cycle.  However,  it 
would  be  a  straightforward  task  to  increase  the  individuals 
within  the  existing  framework  by  populating  the  ontology  with 
additional  classes  and  their  characteristics.  This  would  provide 
a  powerful  decision  support  tool  in  an  expansive  domain. 
Further,  additional  iterations  of  the  PO  Construction  Process 
would  allow  the  introduction  of  additional  relationships  among 
sensors,  weapons,  and  missions  or  alternate  report  types. 
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An  ontology  is  an  explicit,  formal  representation  of 
knowledge  about  a  domain  of  application.  This  includes 

-  Types  of  entities  that  exist  in  the  domain; 

-  Properties  of  those  entities; 

-  Relationships  among  entities; 

-  Processes  and  events  that  happen  with  those  entities; 


where  the  term  entity  refers  to  any  concept  (real  or 
fictitious,  concrete  or  abstract)  that  can  be  described  and 
reasoned  about  within  the  domain  of  application  [costa,2005]. 


“An  ontology  is  an  explicit  specification  of  a  conceptualization  [Gruber,  95]. 


•  Ontologies  provide  a  hierarchical  structure  of  entity 
classes  and  a  formal  way  of  expressing  their 
relationships 

-  First-order  expressivity 

-  Supports  logical  reasoning 

•  There  is  significant  literature  on  engineering  traditional 
ontologies 

•  Ontologies  lack  built-in,  principled  support  to 
adequately  account  for  uncertainty 

-  Annotating  ontologies  with  simple  probability  annotations 
fails  to  convey  structure  of  probabilistic  representation 

-  Less  expressive  probability  schemes  do  not  convey 
ontology  structure,  and  so  are  inadequate 
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A  probabilistic  ontology  is  an  explicit,  formal  representation 
of  knowledge  about  a  domain  of  application.  This  includes 

-  Types  of  entities  that  exist  in  the  domain; 

-  Properties  of  those  entities; 

-  Relationships  among  entities; 

-  Processes  and  events  that  happen  with  those  entities; 

-  Statistical  regularities  that  characterize  the  domain; 

-  Inconclusive,  ambiguous,  incomplete,  unreliable,  and 
dissonant  knowledge  related  to  entities  of  the  domain; 

-  Uncertainty  about  all  the  above  forms  of  knowledge; 


where  the  term  entity  refers  to  any  concept  (real  or 
fictitious,  concrete  or  abstract)  that  can  be  described  and 
reasoned  about  within  the  domain  of  application  [Costa,  2005]. 


A  probabilistic  ontology  extends  a  traditional  ontology  to  represent  uncertainty 
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•  Integrates  inferential  reasoning  power  of  probabilistic 
representations  with  first-order  expressivity  of 
ontologies 

•  Provides  a  means  to  represent  and  reason  with 
uncertainty 

•  Limited  literature  on  construction 


Comprehensively  describes 
knowledge  about  a  domain 
and  the  uncertainty  embedded 
in  that  knowledge  in  a 
principled,  structured  and 
sharable  way  [Brisset,  2003]. 


“It  would  be  interesting  to  have  a 
tool  guiding  the  user  on  the  steps 
necessary  to  create  a  probabilistic 
ontology  and  link  this 
documentation  to  its 
implementation  [Carvalho,  201 1].” 
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Why  Probabilistic  Ontologies? 


Suppose  an  ontology  of  organisms  contains 
the  following  classes  and  relationships: 


Mammal 


V  isA 


Human 


isComposedOf 


Digits 


Limbs 


•  Humans  usually  have: 
-  2  arms  &  2  legs 


-  1 0  fingers  &  1 0  toes 

•  However,  if  a  man  loses  a  limb.... 

-  Is  he  no  longer  human? 
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Premise  of  an  argument  can  be 
uncertain  (e.g.  Humans  have  2  legs): 
(in)validity  of  the  argument  imposes 
no  condition  on  the  certainty  of  the 
conclusion  (an  amputee  is  Human). 


•  The  Semantic  Technologies  (ST)  community  needed  a 
comprehensive  methodology  for  the  development, 
implementation,  and  evaluation  of  probabilistic  ontologies 

-  Ontology  use  is  on  the  rise 

-  A  means  to  incorporate  uncertainty  is  a  necessity 

-  Limited  literature  on  production  of  probabilistic  ontologies 

•  Ontological  engineering  ensures  ontologies  developed  for 
knowledge-sharing  and  reuse  are  explicit,  logical  and  defensible 

•  Standard  ontological  engineering  methods  provide  insufficient 
support  for  complexity  of  probabilistic  ontology  development 


A  similar  methodology  is  needed  for  development  of 

probabilistic  ontologies 
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Create  a  systematic  approach  to  probabilistic  ontology 
development 

•  Facilitated  through  a  reference  architecture 

-  Formalizes  the  application  of  the  methodology 

-  Extensible  to  various  domains 

•  Follows  an  iterative  methodology  applicable  to  any  Systems 
Engineering  development  process 

-  Allows  continuous  expansion  and  evaluation 

-  Simplifies  development  and  logic  checking  through 
spiraling 

•  Ensures  the  implemented  design  meets  requirements 
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The  Process  of  Probabilistic  Ontology  Development 


M«thodoiogy  Layer 


Ontology 

Heuristics  & 
Algorithms 

PODM 

Ontological 

Engineering 

uMdiobtAl 

Knowlecige 
Base  ^ 

Learning 

1 

Ontology  Models 

Probabilistic  Ontology  Architecture 


Operational  Prol>abilistic  Ontology  Implemantation 


Reference  Architecture 
for  PO  Development 


PO  Development 
Methodology  (PODM) 


Probabilistic  Ontology  Development 
Methodology  (PODM) 
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PODM  Background 


PODM  addresses  evolution  of  requirements  into  an  ontology 
that  is  probabilistically-integrated 


-  Explicitly  describes  the  iterative  tasks  required  to 
produce  a  PO  with  in-situ  evaluation  steps 

•  Suitable  for  both  spiral  and  waterfall  development  processes 

•  Application  of  PODM 

-  Specific  decision  problem 

-  Grounded  in  an  inclusive  ontology  representing  its 
entities 


-  Incorporates  probabilities  to  represent  uncertainty 

Establishes  a  solution  grounded  In  an  Inclusive  ontology  representing  Its  entities 
and  incorporation  of  probabilities  to  represent  uncertainty 
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PODM  in  Spiral  Development  Cycle 


EMSo 


Plan  Next  Spiral 

(UP:  Inception) 


Project 

Planning 


Maintain  system 


Upgrade  system 


Support  users 


Analyze  and  Design 

(UP:  Elaboration) 


Analysis 

Phase 


A 


SDLC  Phase 
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Operate  and  Support 

(UP:  Transition) 
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Probabilistic  Ontology  Development 
Methodology 
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Phase 
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Develop  &  Test 


Implementation  Phase 


PO  Construction  Process 


Oniolo^ 

Development 

Activity 


Probablllly 

Incorporation 

Activity 


Evaluation 

Activity 


Loarnlng 

Activity 


Probabilistic 

Learning 

Activity 


Operate  &  Support 


Maintenance,  improvement  and  operationai  support  tasks  to  maintain  currency 
on  the  current  buiid  and  support  user  operation. 


processes 

-  Ensures  interim  steps  evaluated  for  valid  relationships 
and  correct  logic 


•  Based  on  the  Overarching  and  Spiral  Objective  Statements 

•  Defines  the  Spiral  Core  Model 

-  Prime  Queries 

-  Tier-one  Attributes 


Scopes  the  spiral  with  the  stakeholder’s  requirements  and  constraints 


The  Prime  Queries  and  their  associated  Tier-one  attributes  define  the  spiral  Core  Model 
iterated  in  the  construction  cycle  to  create  the  necessary  PO  for  inferential  reasoning 


Ontology  Development  Activity 


Conduct  ontological  engineering 


Research  reusable  ontologies 


Research  heuristics  &  algorithms 


Implement  ontology  model 


Ontological 

Learning 

Activity 


Taxonomy 


Class  Table 


Final  class  diagram 
Formal  Axiom  &  Rules  Table 

V _ J 

Operational  ontology 


•  Summarizes  engineering  tasks  required  to  produce  a  working  ontology 

•  Selection  of  an  ontological  engineering  methodology  is  context  dependent 

•  Fidelity  of  the  ontological  model  is  context  dependent 

•  There  are  tasks  and  products  common  to  each  of  these  processes 
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PROBABILITY  INCORPORATION  ACTIVITY 


GEORGE 


Probability  Incorporation  Activity 


Prime  Query  +  Tier-1  Attributes  =  Spiral  Core  Model 


Completed  Military  Ship  PO 


hasNationalilyCctc^ 


Ship 

r isA(ctc,Ship)  j 

r  isA(rpt,Report)  j 

^  isReportedContact(ctc,  rpt)  ^ 

-J 

Mission 


hasWarshipType(ctc) 


C 


hasPrimaryMsn(ctc) 


) 


WarshipType 


( 


hasWarshipType(ctc) 


) 


^  hasRptType(rpt)  ^ 


J  V 


ShipSize 


( 


hasRptSizeCrpt) 


J 


f - 

Sensor 

Warship  Ciass 


hasPrimaryMsn(ctc) 


hasWeapon(ctc) 


C 


hasShipSensor(ctc) 


3 


Weapon 


hasWarshipType(ctc) 


hasPrimaryMsn(ctc) 


^  hasWeaponCctc)  ^ 


From  an  AOR-specific  library 
(ontology),  the  MilShip  PO 
infers  the  warship  cass  of  an 
unknown  contact  based  on 
limited  or  conflicting  reports 
of  varying  pedigrees 
(uncertainty) . 
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Conduct  elicitation  review 


Draft  case  studies 


Evidence  Table  Case  4 

Variable 

Evidence 

rs1 

hasRptSize(rs  1(  Report  ))=Rpt SizeMedium 

ctc1,  rs1 

i  sReportedCotntact(  ctc1  (Ship  ),rs1  (Report  ))=t  rue 

rt1 

has  R  eportedT  y  pe(  rt  1  ( R  eport )  )=R  pt T  ypeFFG 

ctd.rtl 

isReportedContact(ctc1(Ship),rt1(Report))=true 

ctc1 

hasSensor(ctc1(Ship))=RAS SPY1D 

ctc1 

hasNationality(ctc1((Ship))=Nation DE 

R 


Logical 

Error 


hasShipDisp _ ctcl 

Disp5kto10k 

41.15% 

DispLessSk 

53.86% 

j 

DispGreaterlOk 

4.99% 

absurd 

Q36 

Co 


hasRptSize _ rsl 

RpLSizeLarge  o% 

Rpt SizeMedium  ioo% 

Rpt SizeSmall  o% 

absurd  o% 

_ 

hasShipSize _ ctcl 

SizeMedium 

73.58% 

SizeLarge 

4.04% 

SizeSmall 

22.38% 

absurd 

_ 036 

•  Elicitation 

•  Case  stuc 

-  Cases 

•  Tyi 

-  Errone 
EM&^ 


hasShipLength _ ctcl 

LengthGreaterl  50 

4.99% 

Lengthi  25to1 50 

41.15% 

LengthLessI  25 

53.86% 

absurd 

036 

hasRptType _ rtl 

absurd 

0% 

RpLTypeCVN 

0% 

RpLTypeFF 

0% 

Rpt-TypeFFG 

100% 

■ 

RpLTypeOther 

036 

^ 

hasWarshipCIass _ ctcl 

absurd  o% 

Class CharlesDeGau...  o% 

Class LaFayette  o% 

Class Brandenburg  67.53% 

J 

Class Unknown  32.47% 

Class  Js^lvaroDeBazan  o% 

h  a  sWa  rs  h  i  pTyp  e _ etc  1 

absurd 

0% 

Type  CVN 

0.24% 

Type FFG 

81.25% 

"■ 

Type FF 

7.88% 

Type Other 

10.63% 

hasNationality _ ctcl 

absurd 

0% 

Nation ES 

0% 

Nation FR 

0% 

Nation DE 

100% 

Nation Other 

036 

^ 

hasPrimaryMsn _ ctcl 

Msn ASW 

8.12% 

Msn MW 

91.88% 

■ 

Msn.ASuW 

0% 

absurd 

036 

hasWeapon _ ctcl 

absurd 

8.12% 

WNM Aster1 5 

0% 

WNG Giat 20F2 

0% 

WNG DCNS 

0% 

WNM MM38 

0% 

WNG Mk45 Mod2 

45.33% 

WNM MM40 BIOCk3 

0% 

WNM SM2MR BlockHfe,55% 

WNG Mk75 OtoMelar...  q% 

yVT_Mk46 

_ 036 

hasShipSensor _ ctcl 

absurd 

0% 

RSS SMART 3D 

0% 

RSS DRBV 1 5C 

0% 

RAS DRBV 1 5C 

0% 

SHM DE1 1 60 LF 

0% 

RAS LW08 

0% 

RFC  DORNA 

0% 

SHM DSQS 23BZ 

0% 

RSS ARIES 

0% 

RFC Castor 2J 

0% 

RFC Arabel 

0% 

RAS DRBJ 1 1 B 

0% 

RFC STIR1 80 

0% 

RAS SPY1 D 

100% 

■ 

RSS DRBN34 

036 

^ 

Problem 

•  Ontological  engineering  methodologies  are  unsuitable 
for  production  of  probabilistic  ontologies. 

•  The  literature  on  probabilistic  ontology  development  is 
extremely  limited. 

Solution 

•  Reference  Architecture  for  Probabilistic  Ontology 
Development 

•  Probabilistic  Ontology  Development  Methodology 
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